QRZ! Ham Radio 5

home *** CD-ROM | disk | FTP | other *** search

/ QRZ! Ham Radio 5 / QRZ Ham Radio Callsign Database - Volume 5.iso / files / tcpip / amiga / mb1705.exe / BIDMID.DOC < prev next >

Wrap

Text File | 1993-12-29 | 29.7 KB | 591 lines

This is an initial draft of a "full" explanation of BIDs, MIDs, LIDs, along with message authentication and integrity issues. ------------------------------------------------------------------------ Some comments - I hope that other bbs code authors will also comment ... > ONCE UPON A TIME MESSAGES HAD NO IDENTIFIER, OTHER THAN THE SENDER,RCVR > AND TITLE. Not really true. They always HAD an identifier (the message number and the originating bbs callsign) becuase that is what sysops used to talk about them - just as soon as there were TWO sysops in the world (k1ojh and w0rli, joined a month later by k1bc). This did not cause any problem as there was only one choice of bbs code and not very many bulletins (like two or three per day). A bit later headers were added, and they provided the unique identification for the message. > MESSAGES WERE EASILY DUPLICATED BECAUSE OF THAT, ESPECIALLY WHEN THE FLOOD > DESIGNATORS WERE USED. Flood designators did not exist until roughly 18 months later. They were invented by wa7mbl. > A SMART BYTE SMASHER CAME UP WITH THE IDEA TO GIVE A SPECIAL ID FOR BULLITENS > (FLOOD MESSAGES) AND THROUGH THE EVOLUTION OF THIS CONCEPT A SPECIAL ID FOR > PERSONAL MESSAGES WAS ALSO BEGUN. Not quite true. Nothing different about B or P messages. Those that were given a BID, had one, those that were not given a BID did not have one. Later on, ALL B messages were assigned a BID, whether the user gave them one or not. This was done after discussion between wa7mbl and w0rli. The changes were easy to make: there were only two choices of bbs code - mbl or rli. We talked about the changes, and made them. There was usual difficulty in keeping changes in synch, of course. > SO A "BID" IS A BULLITEN ID (FLOOD) AND A "MID" IS A MESSAGE ID (PERSONAL/NTS). Not at all. A MID is the identifier for any message: B, P, or T. The BID is a SECOND identifier assigned to some messages. Originally, it was ONLY assigned by the user when he entered the message. Later the bbs codes (we still have only two) assigned them automatically, if the user did not specify them. A BID can be assigned to any message. Some BBS codes prohibit assigning a BID to T or to P messages, some allow it. There is not yet a standard on how to handle all the cases. The BID identifies the BODY or CONTENT of the message, the MID identifies the originator of a PARTICULAR message. > NOW THE QUESTION REMAINS... WHAT IS THE "STANDARD" FOR EACH? > WITH ALL CURRENT BBS SYSTEMS TODAY, IT SEEMS THAT EVERY MESSAGE (FLOOD OR > PERSONAL) IS GIVEN A NUMBER. THIS NUMBER IS THE SEQUENTIAL ORDER OF > GENERATION OR ARRIVAL OF EACH MESSAGE AT THAT BBS. For some bbs codes, that is correct. For others it is not. But in all cases, there is SOME unique way to identify each message entered at a bbs, and that unique identifier plus the bbs callsign is all you need to identify the source of the message. Strange as it might seem, we bbs code authors actually talk to each other about these issues, and try to resolve them. > IN FBB (AND IN MOST SYSTEMS IT SEEMS), IF THE GENERATOR OF THE MESSAGE DOES NOT > GIVE A SPECIFIC ID TO THE MESSAGE THEN THE BBS AUTOMATICALLY USES THE MESSAGE > NUMBER COMBINED WITH THE BBS CALL SIGN TO CREATE AN ID FOR THE MESSAGE. For FBB and for MOST of the other BBS codes, that is exactly what happens. For some BBS codes (e.g. some versions of NOS, some codes written in Germany, some unix based codes) other kinds of identification are used. > NOW ACORDING TO THE ABOVE, IF THE MESSAGE IS A FLOOD THEN THE ID IS A BID, > AND CONVERSLY IF THE MESSAGE IS A PERSONAL/NTS THEN THE ID IS A MID. No. The message always has a MID. This is how we talk about the source of the message - where it was entered, what number it had at that bbs. The message may ALSO carry a BID, which may happen to be the same characters as the MID, or may be different. The BID identifies the CONTENT, not the particular message. Several messages may be originated at different bbs systems, each with the same BID. Each has a different MID. It is the BID that allows for multiple entry of the same information at different locations on the network, without having duplicates of that same information appear. > LOOKING THROUGH THE MESSAGES AT THIS BOARD LEADS ME TO CONCLUDE THAT UNLESS > THE ID IS USER GENERATED THAT THERE IS NO DIFFERENCE BETWEEN A BID AND A MID. Did you look into the database, or rely on what the bbs code chose to show you on the screen? How did it display the MID and the BID when both were present (e.g. an AMSAT ORBS-xxx bulletin for example)? > LOOKING THROUGH THE PERSONAL MESSAGES THAT HAVE PASSED THROUGH THIS BOARD, > I FIND THAT MY NEIGHBORS' BBS (AA4RE TYPE, VERSION UNKNOWN) DOES NOT ASSIGN > AN ID TO A PERSONAL MESSAGE (BID/MID WHAT HAVE YOU) AND THIS MESSAGE DOES > NOT HAVE AN ID UNTIL MY FBB RECIEVES THE MESSAGE AND GENERATES ONE USING THE > MESSAGE NUMBER (AS REPORTED IN THE R: LINE) AND THE CALL OF MY NEIGHBORS BBS. > EXAMPLE: #####_BB4AA The ID is there all along. This is the MID. The header is how we send the MID from one system to another. This is how it has been since the begining - at least once we HAD headers - and that is another story. > FROM THE REST OF THE PERSONALS THAT I CAN READ HERE, ALL THE OTHERS EITHER > HAD THIS TYPE OF ID TO BEGIN WITH OR WERE GIVEN ONE IN THE SAME MANNER. > SAME WITH THE BULLITENS, #####_BB4XZ IS THE ID OF THE MESSAGE. > NOW TO EXPLAIN MY CONFUSION, I THOUGHT A "MID" WAS THE SEQUENTIAL NUMBER OF > ASSIGNMENT BY EACH BBS AS THE MESSAGE PASSED THROUGH. THE "22354@N7WVZ" > AS REPORTED IN THE R: LINE RIGHT AFTER THE DATE/TIME, NOT THE 26557_W0RLI > AS ASSIGNED BY THE ORIGIONATING BBS. I THOUGHT THAT THEN A BID AND A MID > WOULD ONLY BE THE SAME AT THE ORIGIONATING BBS, EX: 22458@N7WVZ, 22458_N7WVZ. The MID is (typically) the message number and callsign AT THE ORIGINATING BBS. > SO, NOW IT SEEMS THAT A "BID" AND A "MID" ARE THE SAME THING, ONLY QUALIFIED > BY THE DESTINATION OF THE MESSAGE THEY ID. IS THIS TRUE?? IF SO WHAT'S THE > FUSS?? Not the same thing at all. They often LOOK alike, but the software USES them differently, for different reasons. The MID identifies a particular message. The BID identifies a particular message BODY. > PLEASE REPLY IF THIS IS INCORRECT OR IF YOU CAN EXPLAIN THE PURPOSE OF THE > DISTINCTION. Consider one of those AMSAT ORBS bulletins. It's BID is the typical ORBS-xxxx but it's MID is the callsign of the originating BBS and the message number at that BBS. It is done this way so we can tell where that bulletin was put into the system. > WITH FBB, THE DISTINCTION IS MOOT AS FAR AS I CAN SEE AS THE FORWADING OCCURS > NOT BY THE BID ALONE, BUT BY THE HROUTE. IF THE MESSAGE HAS BEEN PASSED BUT > THE ACK HASN'T BEEN RECEIVED THEN THE PROPOSAL IS RESENT AT THE NEXT FORWARD > TIME AND IS THEN REJECTED BY TO RECEIVING BBS BECAUSE THE BID IS ALLREADY > LOGGED AND THE MESSAGE IS THERE. IF THE MESSAGE DIDN'T GET COMPLETED THEN > THE BID ISN'T LOGGED AND THE PROPOSAL IS ACCEPTED. BULL OR PRIVATE, DOES > NOT MAKE ANY DIFFERENCE, EXCEPT THAT FBB LOOKS AT THE "P" OR "B" AND FORWARDS > THE PRIVATES FIRST. And now we get to the interesting part. > FURTHER, IF THE MESSAGE IS A BULL THEN IT GETS PROPOSED TO EACH BBS THAT I > HAVE SET UP TO RECEIVE BULLS, IF IT'S PRIVATE THEN IT GETS PROPOSED TO > EACH BBS WITH THAT HROUTE IN IT'S FORWARD FILE. EAST GOING HROUTES GO EAST > AND/OR TO THE CLOSEST HUB/HF/INTERNET BBS THAT I KNOW OF. > THIS ALL SEEMS TOO SIMPLE TO BE MAKING AN ISSUE OVER A "BID" AND A "MID" > HAVING THE SAME STRUCTURE/CONTENT. WHY CARE AS LONG AS IT'S UNIQUE ENUF THAT > THE CHANCE OF ANOTHER BBS GENERATING AN EXACT BID/MID TO ANOTHER MESSAGE IS > INFANTESIMAL? IF THE BID USES THE ORIGIONATING BBS CALL THEN THAT IS UNIQUE > ENUF, DON'T YOU THINK? THEN ALSO IF THE MESSAGE IS AN ARRL BULL THEN THE > BID IS SET TO BE UNIQUE FOR THAT BULL (ARRL0243 OR WHAT EVER THE FORMAT IS) > AND THEN WHEN 3 DIFFERENT STATIONS GENERATE THAT BULL WITH THE SAME BID THE > MESSAGE FORWARDS TO EVERY BBS THAT DOESN'T HAVE IT AND ISN'T DUPED AT THE > ONES THAT ALLREADY HAVE IT (WHAT EVER THE SOURCE). And what happens with personal messages? In particular, what happens if a personal message has to be sent BACK to a system you got it from. This will happen, for example, when a personal message is mis-addressed, and needs to be forwarded BACK the same route that you got it from. If the bbs you forward it to rejects it because it's MID has been seen before, that message will be LOST. This is why BIDs and MIDs are different: the bbs code must handle them in different ways. This choice was made way back in the beginning. The options are to suffer a few duplicates (because they will not be rejected) or to lose a few messages (because they will be rejected). The original choice was to suffer a few duplicates rather than to hazard the loss of personal messages. What happens in our network today? Both duplicates and lost messages occur, becuase there is not yet a standard - not even a proposed standard - covering this situation. -------------------------------------------------------------------------- Why are bbs messages and fifty dollar bills different? Fiftry dollar bills each have a unique identifier, don't messages? For messages, we have copies. I have a copy of the bulletin you sent, for example - not the original which is probably still on your system. So we need more identifiers. We need to be able to talk about that original, and the copy I have, and the copy WB7VMS has (I got it from WB7VMS). So we clearly need LIDs (Local IDs) which identify each copy. The MID is simply the LID at station of origin. Now some bulletins have an additional feature: the "same" bulletin is entered in several places. One example is the ORBS information. The copy that I get may have originated at N7DUO by KT7H or may have originated at PA0BBS by DL0WPK. Either one carries the same text, and we don't want duplicates. Thus there is a BID to identify the message text. Each of those two messages also has a MID (showing where it originated) and a LID (it's identity at my system). I will reject duplicate copies no matter where they were originated, because the BID will be the same even though the MID is different. So we have three identities required for a message: 1. BID - unique identifier of the message CONTENT. 2. MID - unique identifier of the individual message at it's point of entry. 3. LID - unique identifier of a copy of the message. ---------------------------------------------------------------------------- From: brianbr77@aol.com To: bbs_authors@Arasmith.COM Date: Wed, 08 Dec 93 21:22:34 EST The LID is the identification of the message on each system where it resides. There is little need for this ID to be considered anywhere outside of that system, EXCEPT the LID from the originating system which can serve as its Message ID for inter-system forwarding. The BID came about for one simple reason - we had a need to be able to enter identical message texts for general interest ARRL and AMSAT materials from multiple entry points without getting dupes. So a 'generic' ID system was created for the various bulletin types. The system works very well. Now obviously each of the initial copies of these bulletins, though the text is identical, is a different message (each has a unique LID/MID from its originating system) unique from the others. In reality they are transported using their BID so that when the copy from Toronto runs into the copy from Plattsburg (NY) in Erie (PA) they stop dead. Non-flood messages are no different in their passing except that they are passed along the (theoretically) most direct route to the addressed BBS. Now the 'deferred disconnect' feature of NR/TN/BPQ generates quite a few duplicates (I still shudder when I think about my 'message from Hell - 4486 bytes, a P to me from a ZS6 that kept timing out in the Hudson River Valley corridor and eventually I actually received 40 some odd copies and Joe, WA2SPL my mail hub killed at least 20 more!) Getting an ID on them will cure much of it. The real problems with a MID passing for non-flood is the worry about loss of message - my system marks them D and the sysop needs to look at it and cause it to be killed or otherwise handled. The other objection is the re-routing. Once again I say that a simple ReMailing routine which strips the message down to its text body and ReMails it with new LID/MID to where ever it should go solves the problem and even older codes don't kill it. The last objection is how to treat T messages. We cannot treat them like flood-messages or we will ultmately have the same message on 4 BBSes and may actually deliver four copies to some unsuspecting recipient. Maybe we should simply pass T-messages sans IDs or pass them with the LID of the passing system so that dupes from system A to system B are eliminated. I see the following problems that need to be resolved before we can make a spec for 'M1' ('M' is out there now, ill defined, so whatever we decide should become 'M1') (1) How do we define what is a 'flood bulletin' - on my system a flood bulletin is any @-address for which I have a support file called address.FLD (like USBBS.FLD) - how do others do it? I realize there is a flaw in my system if I get a message presented SB USERS @ VTNET $TEST001 I store it, save the BID and mark its 'route' NONE. I have to do an LR NONE to find it or else if I see it in passing on general lists. If I anticipated this 'mistake' I might have a translate entry that was *@VTNET *@VTBBS and of course it would get translated and VTBBS.FLD would kick in. (2) Hank and I spoke on the phone and we both agreed that the spec and most of us are a little vague about non-flood bulletins, that is, suppose I want to send a bulletin to USERS@W0RLI.OR.USA.NA from VT. Some systems simply because it is a B will want to treat it like a flood message but will get confused because W0RLI is not a distribution (actually a distribution of 1!) I think most system will handle this OK now, but mostly by accident! I really think we must stop thinking that a message being a 'flood message' is determined by type being 'B' - we need a different criteria, or else we must overhaul how we handle P - that is we would have to send it from here as SP USERS@W0RLI.OR.USA.NA and when it gets to Hanks he has to determine to display it as B or untyped because it is to USERS as opposed to SYSOP ...... (3) we need to agree upon passing T messages - just use LID for specific inter-system transfer. If the other guys gets it Ok we can in good faith kill the T message on our system and it is now his worry? The LID used will only stop dupes between you and that system ... if he gets another copy from elsewhere so be it (4) we need to agree on 'valid' message types, forced typing, and what to do when we get a message type we do not have - I personally think it should be open ended - though once we get to implementing a USENET style 'news group' the need for 'types' to further sub-divide messages goes away. Unfortunately for now we must consider typing as it influence the way some codes handle things. <brian> -------------------------------------------------------------------------- Date: Tue, 16 Nov 93 18:54:04 EST From: ka2bqe@ka2bqe.#nwvt.vt.usa.na (Brian B. Riley) Message-ID: <12522_KA2BQE> (Underhill Ctr, VT) To: sysop@usbbs Subject: IDs Explained In theory there are three different IDs for messages to be dealt with; LID - local ID - some designation of a message on any given system usually simply a number, usually 32 bit long and often only represented as a 16 bit unsigned plus @BBS. EVERY message has a local ID on each system MID - message ID - a way to identify a message to certify its uniqueness through the system to prevent duplication of the message - by implication this applies to any message. It is generally the LID of the message from its orginating system. BID - bulletin ID - a special case of MID. The idea being that often the same message (like AMSAT or ARRL bulletins) would be orginated for distribution purposes from multiple sources. So the idea was that using some set naming convention they would be named generically rather than using the generic LID format for the MID. The BID idea was orginated by Jeff WA7MBL. It worked well enough that many of us decided to apply it to non-flood messages. And then the problems began. At various times various of the BBSes have had the following decision criteria; - if the Send line presents a $ plus a string - its is automatically a bulletin and a flood route is looked for - that had private messages stopped dead since the normal H-route never matched any flood route - any message sent type P was not a flood message and had its BID stripped out - and was then sent back out without BID so that the first sucker to accept it instantly got blamed for 'changing BIDs'! - some systems say that if it is type B it must be a flood bulletin, if it is a P its not - so you cannot do an SB USERS @ K1XXX.MA.USA.NA. - then we have the problems of ID formats, the usual default format for a message-ID is <16 bit unsigned integer in decimal> <_> <orginating BBS callsign> But, since IDs, particularly BIDs can be of any construct, there is no valid grounds for altering/disregarding IDs based upon format, but some BBS codes do! - there is the problem that we have more and more systems running two or three computers and needing a way to identify their system (i.e. 12345_K1RQG1) whihc is fine if you are not a 2x3 callsign. Others have taken to making the ID with <-> instead of <_> and so on. The spec calls for 12 chars. It is a problem we code writers need to look into. Hank's RLI is the one BBS code that has really held out on implementing message ID handling. But his code, like most others can be forced to add an ID to any message just by typing SP KA2BQE @ KA2BQE $. What makes it funny is that all RLI code will properly pass the IDs presented to it ... and what makes it hilarious is that the one system that noone wants to say anything bad about will pass IDs to an RLI system - it is not supposed to send an ID on a non-flood message unless the 'M' is in the SID! The primary objection to M handling for non-flood messages is that if a message gets to a system and has to be re-addressed it may get nailed on the way back out. I addressed this problem in the ReMailer I created for PRMBS, stripping out all of the old headers and assigning a new ID (the one and only time ID strip and re-assignemnet is justified!). Frank Warren, KB4CYC created a package called RMAILER (currently v2.13 avaiable from many HamBBses) based upon my RMAIL/DISTRIBUTION/ReMail concepts that will work with FBB and any other system that will handle standard MBL format import/export files. So in my rarely so humble opinion the point is moot. I hope this answers a lot of the questions that are floating around. <brian> ------------------------------------------------------------------------ Just one thing I noticed. Since WA7MBL did BIDs back in 1985, it has been the case that all "flood messages" must carry a BID, even if addressed SP. This was done to cover the case of SP SYSOP. In about 1987, most existing codes followed this rule, as long as the P message had a distibution. It was also, since 1985, permitted to add a BID to P messages, even if sent to a callsign, and not to a distribution. All the problems began to appear in about 1991-1992 when new codes did not follow the exact same rules as mbl/rli/bqe used, and when aa4re began to transmit MIDs instead of BIDs with the S command for messages which did not have a distribution. This caused the ensuing BID/MID confusion which has lead to the present "disaster". That's the reason my recent code generates BIDs with a different format than usually used to display MIDs - so it will be obvious which is which. The one bug I found with the extensive forwarding tests was that MSYS, FBB, and AA4RE could be set up to ignore the BID presented on the S command. They would accept the message, and then forward it without any BID at all. If the message happened to be to a distribution (a flood message such as SP SYSOP @ WW for example), a dup would be generated just as soon as that message hit any system that requires BID for flood messages - as all must ... How do we cure this? I have no idea. MSYS needs to be fixed so it will never drop a presented BID, and Mike is working on that. I've not heard any positive response from Jean-Paul or from Roy (except that Roy does not yet appear to understand that he needs to hardwire this stuff - sysops are not capable of setting things up right). Say some station forwards to me a message: SP ALL @ ALLOR $1234_N1QRM Is that "1234_N1QRM" a BID, or a MID? Say that same station forwards to me: SP SYSOP @ WW $AMSAT_TEST That is probably a BID ... anyway, it LOOKS like one. Say that same station forwards to me: SB WANT @ USA $1234_N7QSY It's a BID - by definition. Nobody would argue about that. Note that I have no "M" in my SID - so nobody will forward something with "$MID" to me. Now what happens if someone forwards to me: SP SYSOP @ USA I need to add a BID to that message. It is a flood message. Without a BID, there will be millions of dups - it will ping-pong back and forth around the network forever. OK you say, so lets just put a BID on every message. Yes, we thought of that way back in 1985 - there is a problem. A message that must travel back the same path it came will be rejected and lost. This is not good (if you have ever run a major HF forwarding system, you will understand - we toss stuff back and forth as the band conditions change). So the original design was to allow for flood messages - you could tell which ones they were since they had a "$BID" when they were forwarded to you - and to allow for backtracking by all other messages. This worked if: 1) any system that originated a flood message put a BID on it, and 2) no system ever dropped a BID or changed a BID. All was well (or at least "all worked resonably well") until AA4RE decided to do the "M in the SID" thing. That's what started the mess we are in now. I won't even comment on "land line forwarding" - it is not ham radio. Hope this history is helpful - it explains how we got to where we are. ... Hank Date: 04 Dec 93 23:21 Message-ID: <18400@N0ARY> (12736@W0RLI) From: KA2BQE@N0ARY To: W0RLI X-msgtype: P Subject: PRMBS MID/BID Handling From: brianbr77@aol.com To: bbs_authors@Arasmith.COM Date: Sat, 04 Dec 93 18:04:52 EST I have posted this before, but I will reiterate it as it seems to work very well. I assign an ID to every message created upon a PRMBS system. I generate it using the format 12345_KX1XXX, the number being derived by masking out the upper 16 bits of the 32 bit long it used as the LID. If the user specifies an ID on the command line I take that if its is not a dupe. I am changing that since the only code not supporting 'M' is RLI and his code passes the presented ID more perfectly than many of the systems that do! When forwarding I do not 'present' an ID on the send line for non-flood messages to any system that does not have an 'M' in the SID feature list. If I am presenting a non-flood message with an ID capable system I mark it as 'D'upe if it is rejected. I do not kill it. Now when I am recieving messages via forwarding. I take note of the 'presented' ID, if it is not a dupe I OK it and accept the message. I then look down the R: headers. I take note of anything presented on an R: line with a $: and remember the last one I got. I then look for a "Message-ID: <...> field and if present I overide anything that I might have gotten from the R:/$: Now it gets tricky. If no ID was presented, I take whatever was 'recovered' from within and use it. If an ID was presented and what was recovered match, I just go on, if what was presented and what was recovered are different I then check the recovered value against my ID file and if present the message is stored with a status 'D'upe, if it wasn't in the ID file I record it and the mark the ,essage status '?' for sysop review. Either way no flood pointers get generated. I generally can catch any dupe bulletin that has a trace of its orginal BID in it, as well as any duplicate P-messages that orginated on another PRMBS system and many FBB or REBBS systems. This system has been in use now for several years, with the last part about the D/? being in use for 8 months. I have had no complaints of any problems and my sysops tell me it really does catch a lot of the garbage. The last part is the 'return path' problem on re-addressed non-flood messages with IDs. It is quite simple. The ReMailer that Frank Warren, KB4CYC coded from my RMAIL/ROSEDIST code handles all remailing. Recording entire orginal text body of message, the stripping out R: headers synthesizing an barebones RFC-822 header and sending the message back out to its re-addressd destination. - NO ID or R: headers to trip it! RMAILER v2.13 that Frank wrote will work with FBB and with any system that can do MBL format import export. After our heated discussions last spring I revamped PRMBS so that it does no ID changing or 'reconstruction' It will only add an ID to a non-IDed message if it can find an ID somewhere inside it. I call this 'recovered' to keep the idea separate from what Roy and some others do. I for one have to agree with DFD and some others that 'regeneration' of BIDS should not be allowed. It is too fraught with danger. <brian> ------------------------------------------- Message security issues ... As a general comment: if someone creates a "more secure system", someone else will figure out how to break it. Any scheme that relies, for example, on authentication of the connected station only at connect time can be easily broken. Thus, authentication is required on a per-packet basis. (If it is not obvious why this is true, I'll be glad to provide the scenario, think about intercepting an uplink to a netrom node AFTER the password has been accepted - takes only a stronger signal on the uplink. This technique was used in N. Cal. to regain control over a node pair after it's sysop made it do some "real bad things"). So I maintain that we have at least four requirements to consider: 1. Data integrity. A packet channel normally gaurantees this, as does CLOVER. AMTOR, ASCII LL links do not. This is more an operational issue than a technical issue. 2. Authentication of the connected station. I believe we cannot possibly gaurantee this. We CAN add more "stuff" to the connect protocol, for example a "netrom like challange/response sequence". I propose we reserve feature letter P for this - if P is not already in use. This protocol addition would at least gaurantee that the initial few packets came from the station you thought they came from. It provides no gaurantee that the following packets were not provided by some other station. Unless we change to protocols that provide authentication on a per-packet basis, we cannot gaurantee authenticity of data received. 3. Protocol transparency. This we can achieve if we choose to. The issue here is "all systems knowing how to talk to each other by adhering to a common standard." The problem of BIDs truncated to seven characters falls in this realm. We have an initial standard. Every author has reservations about some part of that standard. We could, however, all code to that standard, and thus gaurantee a minimum capability for all systems. Additional capabilities can be negotiated via SID feature letters. All bbs codes handle this pretty well. 4. Traceability. Without 1. and 3., we cannot gaurantee traceability. Think for a bit about a "bad bbs system" that chooses to alter the tracking information. No problem providing the correct CRC (if CRC protection is used). Header strippers, header "normalization" code, header munging by noisy LL connections, character translation by AMTOR all cause this to happen now. In most cases, the damage is done only by buggy code. It could, however, be done intentionally (see comment below). Most bbs codes provide the sysop with log files which record all significant transactions on their message base. Messages can be traced both by their headers and by the traces they leave in log files. This technique was used in New England to track down a bootlegger way back in 1985 - even though the message headers were altered, the log files of the bbs in the area were examined, and the message trail reconstructed from transaction time stamps. > My concern over sysops or others altering msg content or fake msgs is very real and this issue has not been the subject of public debate. I recognize that no system is completely foolproof but currently there are no intergity controls. You or I or any sysop could easily receive a letter from the FCC alleging that we allowed an illegal msg into the system and be completely innocent. > If I release a bltn, I would like to have some assurance that the content of that bltn will be maintained. I think this is not possible. > Anyone can take any bltn, change the contents and send it back out with entirely different text. Or originate a bltn and substitute another callsign. This has already been done, with the headers jimmied to make station of origin and first few forwarding hops look realistic. It is very simple to do ... Didn't get all that much hate mail from it though.